Various forms of network-based storage systems are known today. These forms include network attached storage (NAS), storage area networks (SANs), and others. Network storage systems are commonly used for a variety of purposes, such as providing multiple users with access to shared data, backing up critical data (e.g., by data mirroring), etc.
A network-based storage system typically includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (“clients”). In the context of NAS, a storage server may be a file server, which is sometimes called a “filer”. A filer operates on behalf of one or more clients to store and manage shared files. The files may be stored in a storage subsystem that includes one or more arrays of mass storage devices, such as magnetic or optical disks or tapes, by using RAID (Redundant Array of Inexpensive Disks). Hence, the mass storage devices in each array may be organized into one or more separate RAID groups.
In a SAN context, a storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain Filers made by Network Appliance, Inc. (NetApp®) of Sunnyvale, Calif.
In conventional file servers, data is stored in logical containers called volumes and aggregates. An “aggregate” is a logical container for a pool of storage, combining one or more physical mass storage devices (e.g., disks) or parts thereof into a single logical storage object, which contains or provides storage for one or more other logical data sets at a higher level of abstraction (e.g., volumes). A “volume” is a set of stored data associated with a collection of mass storage devices, such as disks, which obtains its storage from (i.e., is contained within) an aggregate, and which is managed as an independent administrative unit, such as a complete file system. A “file system” is an independently managed, self-contained, hierarchal set of data units (e.g., files, blocks or LUNs). Although a volume or file system (as those terms are used herein) may store data in the form of files, that is not necessarily the case. That is, a volume or file system may store data in the form of other units, such as blocks or LUNs.
A storage server may maintain at least one write-out-of-place file system. In a “write-out-of-place” file system, whenever a data block is modified, it is written to a new physical location on disk. This is in contrast with a “write-in-place” approach, where a data block, when modified, is written in its modified form back to the same physical location on disk. An example of file system software that implements write-out-of-place is the WAFL® file system software included in the Data ONTAP® storage operating system of NetApp.
One feature which is useful to have in a storage server is the ability to create a read-only, persistent, point-in-time image (RPPI) of a data set, such as a volume or a LUN, including its metadata. This capability allows the exact state of the data set to be restored from the RPPI in the event of, for example, a catastrophic failure of the storage system or data corruption. The ability to restore data from an RPPI provides administrators with a simple mechanism to revert the state of their data to a known previous point in time as captured by the RPPI. Typically, creation of an RPPI or restoration from an RPPI can be controlled from a client-side software tool. An example of an implementation of an RPPI is a Snapshot™, which can be generated by SnapDrive™ or SME (SnapManager® for Microsoft® Exchange), both made by NetApp. (The term “Snapshot” is used in this document without derogation of Network Appliance, Inc.'s trademark rights.) Unlike other RPPI implementations, NetApp Snapshots do not require duplication of data blocks in the active file system, because a Snapshot can include pointers to data blocks in the active file system. The “active” file system is the current working file system, where data may be modified or deleted, as opposed to an RPPI, which is a read-only copy of the file system saved at a specific time.
An example of an RPPI technique which does not require duplication of data blocks to create an RPPI is described in U.S. Pat. No. 5,819,292, which is incorporated herein by reference, and which is assigned to NetApp. The described technique of creating an RPPI (e.g., a Snapshot) does not require duplication of data blocks in the active file system, because the active file system can include pointers to data blocks in an RPPI, for any blocks that have not been modified since the RPPI was created. Among other advantages, this technique allows an RPPI to be created quickly, helps to reduce consumption of storage space due to RPPIs, and reduces the need to repeatedly update data block pointers as required in some prior art RPPI techniques.
Traditionally, during the boot up of a storage server, the operating system of the storage server mounts all of its file systems, including the RPPIs. Mounting a file system includes allocating in-core data structures within the memory of the storage server and reading the metadata of the file system from the mass storage system, i.e., the disk(s), into the allocated data structures. Metadata of a file system describes, for example, the structure of the whole file system, including free space, and provides a basis for locating and accessing data stored in the file system and also managing the file system. The same steps are required to mount an RPPI of a file system. Since the metadata can be stored anywhere on the disk(s), the load involves random disk accesses incurring seeking and rotational latencies. As the number of RPPIs in a file system increases, so does the time needed to mount them. This causes boot time of a storage server to increase linearly with the increase of the number of RPPIs maintained on the storage server. Because a storage server is not accessible during boot up, longer boot time would negatively affect the storage server's availability.